diff options
Diffstat (limited to 'doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt')
| -rw-r--r-- | doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt | 3083 |
1 files changed, 0 insertions, 3083 deletions
diff --git a/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt b/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt deleted file mode 100644 index 9169d78be..000000000 --- a/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt +++ /dev/null @@ -1,3083 +0,0 @@ - - - - - - -Network Working Group H. Orman -Request for Comments: 2412 Department of Computer Science -Category: Informational University of Arizona - November 1998 - - - The OAKLEY Key Determination Protocol - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document describes a protocol, named OAKLEY, by which two - authenticated parties can agree on secure and secret keying material. - The basic mechanism is the Diffie-Hellman key exchange algorithm. - - The OAKLEY protocol supports Perfect Forward Secrecy, compatibility - with the ISAKMP protocol for managing security associations, user- - defined abstract group structures for use with the Diffie-Hellman - algorithm, key updates, and incorporation of keys distributed via - out-of-band mechanisms. - -1. INTRODUCTION - - Key establishment is the heart of data protection that relies on - cryptography, and it is an essential component of the packet - protection mechanisms described in [RFC2401], for example. A - scalable and secure key distribution mechanism for the Internet is a - necessity. The goal of this protocol is to provide that mechanism, - coupled with a great deal of cryptographic strength. - - The Diffie-Hellman key exchange algorithm provides such a mechanism. - It allows two parties to agree on a shared value without requiring - encryption. The shared value is immediately available for use in - encrypting subsequent conversation, e.g. data transmission and/or - authentication. The STS protocol [STS] provides a demonstration of - how to embed the algorithm in a secure protocol, one that ensures - that in addition to securely sharing a secret, the two parties can be - sure of each other's identities, even when an active attacker exists. - - - - -Orman Informational [Page 1] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Because OAKLEY is a generic key exchange protocol, and because the - keys that it generates might be used for encrypting data with a long - privacy lifetime, 20 years or more, it is important that the - algorithms underlying the protocol be able to ensure the security of - the keys for that period of time, based on the best prediction - capabilities available for seeing into the mathematical future. The - protocol therefore has two options for adding to the difficulties - faced by an attacker who has a large amount of recorded key exchange - traffic at his disposal (a passive attacker). These options are - useful for deriving keys which will be used for encryption. - - The OAKLEY protocol is related to STS, sharing the similarity of - authenticating the Diffie-Hellman exponentials and using them for - determining a shared key, and also of achieving Perfect Forward - Secrecy for the shared key, but it differs from the STS protocol in - several ways. - - The first is the addition of a weak address validation mechanism - ("cookies", described by Phil Karn in the Photuris key exchange - protocol work in progress) to help avoid denial of service - attacks. - - The second extension is to allow the two parties to select - mutually agreeable supporting algorithms for the protocol: the - encryption method, the key derivation method, and the - authentication method. - - Thirdly, the authentication does not depend on encryption using - the Diffie-Hellman exponentials; instead, the authentication - validates the binding of the exponentials to the identities of the - parties. - - The protocol does not require the two parties compute the shared - exponentials prior to authentication. - - This protocol adds additional security to the derivation of keys - meant for use with encryption (as opposed to authentication) by - including a dependence on an additional algorithm. The derivation - of keys for encryption is made to depend not only on the Diffie- - Hellman algorithm, but also on the cryptographic method used to - securely authenticate the communicating parties to each other. - - Finally, this protocol explicitly defines how the two parties can - select the mathematical structures (group representation and - operation) for performing the Diffie-Hellman algorithm; they can - use standard groups or define their own. User-defined groups - provide an additional degree of long-term security. - - - - -Orman Informational [Page 2] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - OAKLEY has several options for distributing keys. In addition to the - classic Diffie-Hellman exchange, this protocol can be used to derive - a new key from an existing key and to distribute an externally - derived key by encrypting it. - - The protocol allows two parties to use all or some of the anti- - clogging and perfect forward secrecy features. It also permits the - use of authentication based on symmetric encryption or non-encryption - algorithms. This flexibility is included in order to allow the - parties to use the features that are best suited to their security - and performance requirements. - - This document draws extensively in spirit and approach from the - Photuris work in progress by Karn and Simpson (and from discussions - with the authors), specifics of the ISAKMP document by Schertler et - al. the ISAKMP protocol document, and it was also influenced by - papers by Paul van Oorschot and Hugo Krawcyzk. - -2. The Protocol Outline - -2.1 General Remarks - - The OAKLEY protocol is used to establish a shared key with an - assigned identifier and associated authenticated identities for the - two parties. The name of the key can be used later to derive - security associations for the RFC 2402 and RFC 2406 protocols (AH and - ESP) or to achieve other network security goals. - - Each key is associated with algorithms that are used for - authentication, privacy, and one-way functions. These are ancillary - algorithms for OAKLEY; their appearance in subsequent security - association definitions derived with other protocols is neither - required nor prohibited. - - The specification of the details of how to apply an algorithm to data - is called a transform. This document does not supply the transform - definitions; they will be in separate RFC's. - - The anti-clogging tokens, or "cookies", provide a weak form of source - address identification for both parties; the cookie exchange can be - completed before they perform the computationally expensive part of - the protocol (large integer exponentiations). - - It is important to note that OAKLEY uses the cookies for two - purposes: anti-clogging and key naming. The two parties to the - protocol each contribute one cookie at the initiation of key - establishment; the pair of cookies becomes the key identifier - (KEYID), a reusable name for the keying material. Because of this - - - -Orman Informational [Page 3] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - dual role, we will use the notation for the concatenation of the - cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol - "KEYID". - - OAKLEY is designed to be a compatible component of the ISAKMP - protocol [ISAKMP], which runs over the UDP protocol using a well- - known port (see the RFC on port assignments, STD02-RFC-1700). The - only technical requirement for the protocol environment is that the - underlying protocol stack must be able to supply the Internet address - of the remote party for each message. Thus, OAKLEY could, in theory, - be used directly over the IP protocol or over UDP, if suitable - protocol or port number assignments were available. - - The machine running OAKLEY must provide a good random number - generator, as described in [RANDOM], as the source of random numbers - required in this protocol description. Any mention of a "nonce" - implies that the nonce value is generated by such a generator. The - same is true for "pseudorandom" values. - -2.2 Notation - - The section describes the notation used in this document for message - sequences and content. - -2.2.1 Message descriptions - - The protocol exchanges below are written in an abbreviated notation - that is intended to convey the essential elements of the exchange in - a clear manner. A brief guide to the notation follows. The detailed - formats and assigned values are given in the appendices. - - In order to represent message exchanges succinctly, this document - uses an abbreviated notation that describes each message in terms of - its source and destination and relevant fields. - - Arrows ("->") indicate whether the message is sent from the initiator - to the responder, or vice versa ("<-"). - - The fields in the message are named and comma separated. The - protocol uses the convention that the first several fields constitute - a fixed header format for all messages. - - For example, consider a HYPOTHETICAL exchange of messages involving a - fixed format message, the four fixed fields being two "cookies", the - third field being a message type name, the fourth field being a - multi-precision integer representing a power of a number: - - - - - -Orman Informational [Page 4] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Initiator Responder - -> Cookie-I, 0, OK_KEYX, g^x -> - <- Cookie-R, Cookie-I, OK_KEYX, g^y <- - - The notation describes a two message sequence. The initiator begins - by sending a message with 4 fields to the responder; the first field - has the unspecified value "Cookie-I", second field has the numeric - value 0, the third field indicates the message type is OK_KEYX, the - fourth value is an abstract group element g to the x'th power. - - The second line indicates that the responder replies with value - "Cookie-R" in the first field, a copy of the "Cookie-I" value in the - second field, message type OK_KEYX, and the number g raised to the - y'th power. - - The value OK_KEYX is in capitals to indicate that it is a unique - constant (constants are defined in the appendices). - - Variable precision integers with length zero are null values for the - protocol. - - Sometimes the protocol will indicate that an entire payload (usually - the Key Exchange Payload) has null values. The payload is still - present in the message, for the purpose of simplifying parsing. - -2.2.2 Guide to symbols - - Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random - numbers. The generation method must ensure with high probability - that the numbers used for each IP remote address are unique over some - time period, such as one hour. - - KEYID is the concatenation of the initiator and responder cookies and - the domain of interpretation; it is the name of keying material. - - sKEYID is used to denote the keying material named by the KEYID. It - is never transmitted, but it is used in various calculations - performed by the two parties. - - OK_KEYX and OK_NEWGRP are distinct message types. - - IDP is a bit indicating whether or not material after the encryption - boundary (see appendix B), is encrypted. NIDP means not encrypted. - - g^x and g^y are encodings of group elements, where g is a special - group element indicated in the group description (see Appendix A) and - g^x indicates that element raised to the x'th power. The type of the - encoding is either a variable precision integer or a pair of such - - - -Orman Informational [Page 5] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - integers, as indicated in the group operation in the group - description. Note that we will write g^xy as a short-hand for - g^(xy). See Appendix F for references that describe implementing - large integer computations and the relationship between various group - definitions and basic arithmetic operations. - - EHAO is a list of encryption/hash/authentication choices. Each item - is a pair of values: a class name and an algorithm name. - - EHAS is a set of three items selected from the EHAO list, one from - each of the classes for encryption, hash, authentication. - - GRP is a name (32-bit value) for the group and its relevant - parameters: the size of the integers, the arithmetic operation, and - the generator element. There are a few pre-defined GRP's (for 768 - bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, - 155-bit and 210-bit elliptic curves, see Appendix E), but - participants can share other group descriptions in a later protocol - stage (see the section NEW GROUP). It is important to separate - notion of the GRP from the group descriptor (Appendix A); the former - is a name for the latter. - - The symbol vertical bar "|" is used to denote concatenation of bit - strings. Fields are concatenated using their encoded form as they - appear in their payload. - - Ni and Nr are nonces selected by the initiator and responder, - respectively. - - ID(I) and ID(R) are the identities to be used in authenticating the - initiator and responder respectively. - - E{x}Ki indicates the encryption of x using the public key of the - initiator. Encryption is done using the algorithm associated with - the authentication method; usually this will be RSA. - - S{x}Ki indicates the signature over x using the private key (signing - key) of the initiator. Signing is done using the algorithm - associated with the authentication method; usually this will be RSA - or DSS. - - prf(a, b) denotes the result of applying pseudo-random function "a" - to data "b". One may think of "a" as a key or as a value that - characterizes the function prf; in the latter case it is the index - into a family of functions. Each function in the family provides a - "hash" or one-way mixing of the input. - - prf(0, b) denotes the application of a one-way function to data "b". - - - -Orman Informational [Page 6] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The similarity with the previous notation is deliberate and indicates - that a single algorithm, e.g. MD5, might will used for both purposes. - In the first case a "keyed" MD5 transform would be used with key "a"; - in the second case the transform would have the fixed key value zero, - resulting in a one-way function. - - The term "transform" is used to refer to functions defined in - auxiliary RFC's. The transform RFC's will be drawn from those - defined for IPSEC AH and ESP (see RFC 2401 for the overall - architecture encompassing these protocols). - -2.3 The Key Exchange Message Overview - - The goal of key exchange processing is the secure establishment of - common keying information state in the two parties. This state - information is a key name, secret keying material, the identification - of the two parties, and three algorithms for use during - authentication: encryption (for privacy of the identities of the two - parties), hashing (a pseudorandom function for protecting the - integrity of the messages and for authenticating message fields), and - authentication (the algorithm on which the mutual authentication of - the two parties is based). The encodings and meanings for these - choices are presented in Appendix B. - - The main mode exchange has five optional features: stateless cookie - exchange, perfect forward secrecy for the keying material, secrecy - for the identities, perfect forward secrecy for identity secrecy, use - of signatures (for non-repudiation). The two parties can use any - combination of these features. - - The general outline of processing is that the Initiator of the - exchange begins by specifying as much information as he wishes in his - first message. The Responder replies, supplying as much information - as he wishes. The two sides exchange messages, supplying more - information each time, until their requirements are satisfied. - - The choice of how much information to include in each message depends - on which options are desirable. For example, if stateless cookies - are not a requirement, and identity secrecy and perfect forward - secrecy for the keying material are not requirements, and if non- - repudiatable signatures are acceptable, then the exchange can be - completed in three messages. - - Additional features may increase the number of roundtrips needed for - the keying material determination. - - ISAKMP provides fields for specifying the security association - parameters for use with the AH and ESP protocols. These security - - - -Orman Informational [Page 7] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - association payload types are specified in the ISAKMP memo; the - payload types can be protected with OAKLEY keying material and - algorithms, but this document does not discuss their use. - -2.3.1 The Essential Key Exchange Message Fields - - There are 12 fields in an OAKLEY key exchange message. Not all the - fields are relevant in every message; if a field is not relevant it - can have a null value or not be present (no payload). - - CKY-I originator cookie. - CKY-R responder cookie. - MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or - ISA_KE&AUTH_REP; for new group definitions, - will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP - GRP the name of the Diffie-Hellman group used for - the exchange - g^x (or g^y) variable length integer representing a power of - group generator - EHAO or EHAS encryption, hash, authentication functions, - offered and selectedj, respectively - IDP an indicator as to whether or not encryption with - g^xy follows (perfect forward secrecy for ID's) - ID(I) the identity for the Initiator - ID(R) the identity for the Responder - Ni nonce supplied by the Initiator - Nr nonce supplied by the Responder - - The construction of the cookies is implementation dependent. Phil - Karn has recommended making them the result of a one-way function - applied to a secret value (changed periodically), the local and - remote IP address, and the local and remote UDP port. In this way, - the cookies remain stateless and expire periodically. Note that with - OAKLEY, this would cause the KEYID's derived from the secret value to - also expire, necessitating the removal of any state information - associated with it. - - In order to support pre-distributed keys, we recommend that - implementations reserve some portion of their cookie space to - permanent keys. The encoding of these depends only on the local - implementation. - - The encryption functions used with OAKLEY must be cryptographic - transforms which guarantee privacy and integrity for the message - data. Merely using DES in CBC mode is not permissible. The - MANDATORY and OPTIONAL transforms will include any that satisfy this - criteria and are defined for use with RFC 2406 (ESP). - - - - -Orman Informational [Page 8] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The one-way (hash) functions used with OAKLEY must be cryptographic - transforms which can be used as either keyed hash (pseudo-random) or - non-keyed transforms. The MANDATORY and OPTIONAL transforms will - include any that are defined for use with RFC 2406 (AH). - - Where nonces are indicated, they will be variable precision integers - with an entropy value that matches the "strength" attribute of the - GRP used with the exchange. If no GRP is indicated, the nonces must - be at least 90 bits long. The pseudo-random generator for the nonce - material should start with initial data that has at least 90 bits of - entropy; see RFC 1750. - -2.3.1.1 Exponent Advice - - Ideally, the exponents will have at least 180 bits of entropy for - every key exchange. This ensures complete independence of keying - material between two exchanges (note that this applies if only one of - the parties chooses a random exponent). In practice, implementors - may wish to base several key exchanges on a single base value with - 180 bits of entropy and use one-way hash functions to guarantee that - exposure of one key will not compromise others. In this case, a good - recommendation is to keep the base values for nonces and cookies - separate from the base value for exponents, and to replace the base - value with a full 180 bits of entropy as frequently as possible. - - The values 0 and p-1 should not be used as exponent values; - implementors should be sure to check for these values, and they - should also refuse to accept the values 1 and p-1 from remote parties - (where p is the prime used to define a modular exponentiation group). - -2.3.2 Mapping to ISAKMP Message Structures - - All the OAKLEY message fields correspond to ISAKMP message payloads - or payload components. The relevant payload fields are the SA - payload, the AUTH payload, the Certificate Payload, the Key Exchange - Payload. The ISAKMP protocol framwork is a work in progress at this - time, and the exact mapping of Oakley message fields to ISAKMP - payloads is also in progress (to be known as the Resolution - document). - - Some of the ISAKMP header and payload fields will have constant - values when used with OAKLEY. The exact values to be used will be - published in a Domain of Interpretation document accompanying the - Resolution document. - - In the following we indicate where each OAKLEY field appears in the - ISAKMP message structure. These are recommended only; the Resolution - document will be the final authority on this mapping. - - - -Orman Informational [Page 9] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - CKY-I ISAKMP header - CKY-R ISAKMP header - MSGTYPE Message Type in ISAKMP header - GRP SA payload, Proposal section - g^x (or g^y) Key Exchange Payload, encoded as a variable - precision integer - EHAO and EHAS SA payload, Proposal section - IDP A bit in the RESERVED field in the AUTH header - ID(I) AUTH payload, Identity field - ID(R) AUTH payload, Identity field - Ni AUTH payload, Nonce Field - Nr AUTH payload, Nonce Field - S{...}Kx AUTH payload, Data Field - prf{K,...} AUTH payload, Data Field - -2.4 The Key Exchange Protocol - - The exact number and content of messages exchanged during an OAKLEY - key exchange depends on which options the Initiator and Responder - want to use. A key exchange can be completed with three or more - messages, depending on those options. - - The three components of the key determination protocol are the - - 1. cookie exchange (optionally stateless) - 2. Diffie-Hellman half-key exchange (optional, but essential for - perfect forward secrecy) - 3. authentication (options: privacy for ID's, privacy for ID's - with PFS, non-repudiatable) - - The initiator can supply as little information as a bare exchange - request, carrying no additional information. On the other hand the - initiator can begin by supplying all of the information necessary for - the responder to authenticate the request and complete the key - determination quickly, if the responder chooses to accept this - method. If not, the responder can reply with a minimal amount of - information (at the minimum, a cookie). - - The method of authentication can be digital signatures, public key - encryption, or an out-of-band symmetric key. The three different - methods lead to slight variations in the messages, and the variations - are illustrated by examples in this section. - - The Initiator is responsible for retransmitting messages if the - protocol does not terminate in a timely fashion. The Responder must - therefore avoid discarding reply information until it is acknowledged - by Initiator in the course of continuing the protocol. - - - - -Orman Informational [Page 10] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The remainder of this section contains examples demonstrating how to - use OAKLEY options. - -2.4.1 An Aggressive Example - - The following example indicates how two parties can complete a key - exchange in three messages. The identities are not secret, the - derived keying material is protected by PFS. - - By using digital signatures, the two parties will have a proof of - communication that can be recorded and presented later to a third - party. - - The keying material implied by the group exponentials is not needed - for completing the exchange. If it is desirable to defer the - computation, the implementation can save the "x" and "g^y" values and - mark the keying material as "uncomputed". It can be computed from - this information later. - - Initiator Responder - --------- --------- - -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> - ID(I), ID(R), Ni, 0, - S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki - <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, - ID(R), ID(I), Nr, Ni, - S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <- - -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, -> - ID(I), ID(R), Ni, Nr, - S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki - - NB "NIDP" means that the PFS option for hiding identities is not used. - i.e., the identities are not encrypted using a key based on g^xy - - NB Fields are shown separated by commas in this document; they are - concatenated in the actual protocol messages using their encoded - forms as specified in the ISAKMP/Oakley Resolution document. - - The result of this exchange is a key with KEYID = CKY-I|CKY-R and - value - - sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). - - The processing outline for this exchange is as follows: - - - - - - - -Orman Informational [Page 11] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Initiation - - The Initiator generates a unique cookie and associates it with the - expected IP address of the responder, and its chosen state - information: GRP (the group identifier), a pseudo-randomly - selected exponent x, g^x, EHAO list, nonce, identities. The first - authentication choice in the EHAO list is an algorithm that - supports digital signatures, and this is used to sign the ID's and - the nonce and group id. The Initiator further - - notes that the key is in the initial state of "unauthenticated", - and - - sets a timer for possible retransmission and/or termination of the - request. - - When the Responder receives the message, he may choose to ignore all - the information and treat it as merely a request for a cookie, - creating no state. If CKY-I is not already in use by the source - address in the IP header, the responder generates a unique cookie, - CKY-R. The next steps depend on the Responder's preferences. The - minimal required response is to reply with the first cookie field set - to zero and CKY-R in the second field. For this example we will - assume that the responder is more aggressive (for the alternatives, - see section 6) and accepts the following: - - group with identifier GRP, - first authentication choice (which must be the digital signature - method used to sign the Initiator message), - lack of perfect forward secrecy for protecting the identities, - identity ID(I) and identity ID(R) - - In this example the Responder decides to accept all the information - offered by the initiator. It validates the signature over the signed - portion of the message, and associate the pair (CKY-I, CKY-R) with - the following state information: - - the source and destination network addresses of the message - - key state of "unauthenticated" - - the first algorithm from the authentication offer - - group GRP, a "y" exponent value in group GRP, and g^x from the - message - - the nonce Ni and a pseudorandomly selected value Nr - - - - -Orman Informational [Page 12] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - a timer for possible destruction of the state. - - The Responder computes g^y, forms the reply message, and then signs - the ID and nonce information with the private key of ID(R) and sends - it to the Initiator. In all exchanges, each party should make sure - that he neither offers nor accepts 1 or g^(p-1) as an exponential. - - In this example, to expedite the protocol, the Responder implicitly - accepts the first algorithm in the Authentication class of the EHAO - list. This because he cannot validate the Initiator signature - without accepting the algorithm for doing the signature. The - Responder's EHAS list will also reflect his acceptance. - - The Initiator receives the reply message and - validates that CKY-I is a valid association for the network - address of the incoming message, - - adds the CKY-R value to the state for the pair (CKY-I, network - address), and associates all state information with the pair - (CKY-I, CKY-R), - - validates the signature of the responder over the state - information (should validation fail, the message is discarded) - - adds g^y to its state information, - - saves the EHA selections in the state, - - optionally computes (g^y)^x (= g^xy) (this can be deferred until - after sending the reply message), - - sends the reply message, signed with the public key of ID(I), - - marks the KEYID (CKY-I|CKY-R) as authenticated, - - and composes the reply message and signature. - - When the Responder receives the Initiator message, and if the - signature is valid, it marks the key as being in the authenticated - state. It should compute g^xy and associate it with the KEYID. - - Note that although PFS for identity protection is not used, PFS for - the derived keying material is still present because the Diffie- - Hellman half-keys g^x and g^y are exchanged. - - Even if the Responder only accepts some of the Initiator information, - the Initiator will consider the protocol to be progressing. The - Initiator should assume that fields that were not accepted by the - - - -Orman Informational [Page 13] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Responder were not recorded by the Responder. - - If the Responder does not accept the aggressive exchange and selects - another algorithm for the A function, then the protocol will not - continue using the signature algorithm or the signature value from - the first message. - -2.4.1.1 Fields Not Present - - If the Responder does not accept all the fields offered by the - Initiator, he should include null values for those fields in his - response. Section 6 has guidelines on how to select fields in a - "left-to-right" manner. If a field is not accepted, then it and all - following fields must have null values. - - The Responder should not record any information that it does not - accept. If the ID's and nonces have null values, there will not be a - signature over these null values. - -2.4.1.2 Signature via Pseudo-Random Functions - - The aggressive example is written to suggest that public key - technology is used for the signatures. However, a pseudorandom - function can be used, if the parties have previously agreed to such a - scheme and have a shared key. - - If the first proposal in the EHAO list is an "existing key" method, - then the KEYID named in that proposal will supply the keying material - for the "signature" which is computed using the "H" algorithm - associated with the KEYID. - - Suppose the first proposal in EHAO is - EXISTING-KEY, 32 - and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation. - The keying material is some string of bits, call it sK32. Then in - the first message in the aggressive exchange, where the signature - - S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki - - is indicated, the signature computation would be performed by - MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x - | g^y | EHAO) (The exact definition of the algorithm corresponding - to "MD5-HMAC- func" will appear in the RFC defining that transform). - - The result of this computation appears in the Authentication payload. - - - - - - -Orman Informational [Page 14] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.4.2 An Aggressive Example With Hidden Identities - - The following example indicates how two parties can complete a key - exchange without using digital signatures. Public key cryptography - hides the identities during authentication. The group exponentials - are exchanged and authenticated, but the implied keying material - (g^xy) is not needed during the exchange. - - This exchange has an important difference from the previous signature - scheme --- in the first message, an identity for the responder is - indicated as cleartext: ID(R'). However, the identity hidden with - the public key cryptography is different: ID(R). This happens - because the Initiator must somehow tell the Responder which - public/private key pair to use for the decryption, but at the same - time, the identity is hidden by encryption with that public key. - - The Initiator might elect to forgo secrecy of the Responder identity, - but this is undesirable. Instead, if there is a well-known identity - for the Responder node, the public key for that identity can be used - to encrypt the actual Responder identity. - - Initiator Responder - --------- --------- - -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> - ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' - <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, - E{ID(R), ID(I), Nr}Ki, - prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <- - -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, - prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) -> - - Kir = prf(0, Ni | Nr) - - NB "NIDP" means that the PFS option for hiding identities is not used. - - NB The ID(R') value is included in the Authentication payload as - described in Appendix B. - - The result of this exchange is a key with KEYID = CKY-I|CKY-R and - value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). - - The processing outline for this exchange is as follows: - - Initiation - The Initiator generates a unique cookie and associates it with the - expected IP address of the responder, and its chosen state - information: GRP, g^x, EHAO list. The first authentication choice - in the EHAO list is an algorithm that supports public key - - - -Orman Informational [Page 15] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - encryption. The Initiator also names the two identities to be - used for the connection and enters these into the state. A well- - known identity for the responder machine is also chosen, and the - public key for this identity is used to encrypt the nonce Ni and - the two connection identities. The Initiator further - - notes that the key is in the initial state of "unauthenticated", - and - - sets a timer for possible retransmission and/or termination of the - request. - - When the Responder receives the message, he may choose to ignore all - the information and treat it as merely a request for a cookie, - creating no state. - - If CKY-I is not already in use by the source address in the IP - header, the Responder generates a unique cookie, CKY-R. As before, - the next steps depend on the responder's preferences. The minimal - required response is a message with the first cookie field set to - zero and CKY-R in the second field. For this example we will assume - that responder is more aggressive and accepts the following: - - group GRP, first authentication choice (which must be the public - key encryption algorithm used to encrypt the payload), lack of - perfect forward secrecy for protecting the identities, identity - ID(I), identity ID(R) - - The Responder must decrypt the ID and nonce information, using the - private key for the R' ID. After this, the private key for the R ID - will be used to decrypt the nonce field. - - The Responder now associates the pair (CKY-I, CKY-R) with the - following state information: - - the source and destination network addresses of the message - - key state of "unauthenticated" - - the first algorithm from each class in the EHAO (encryption-hash- - authentication algorithm offers) list - - group GRP and a y and g^y value in group GRP - - the nonce Ni and a pseudorandomly selected value Nr - - a timer for possible destruction of the state. - - - - -Orman Informational [Page 16] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The Responder then encrypts the state information with the public key - of ID(I), forms the prf value, and sends it to the Initiator. - - The Initiator receives the reply message and - validates that CKY-I is a valid association for the network - address of the incoming message, - - adds the CKY-R value to the state for the pair (CKY-I, network - address), and associates all state information with the pair - (CKY-I, CKY-R), - - decrypts the ID and nonce information - - checks the prf calculation (should this fail, the message is - discarded) - - adds g^y to its state information, - - saves the EHA selections in the state, - - optionally computes (g^x)^y (= g^xy) (this may be deferred), and - - sends the reply message, encrypted with the public key of ID(R), - - and marks the KEYID (CKY-I|CKY-R) as authenticated. - - When the Responder receives this message, it marks the key as being - in the authenticated state. If it has not already done so, it should - compute g^xy and associate it with the KEYID. - - The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | - CKY-R) - - Note that although PFS for identity protection is not used, PFS for - the derived keying material is still present because the Diffie- - Hellman half-keys g^x and g^y are exchanged. - -2.4.3 An Aggressive Example With Private Identities and Without Diffie- - Hellman - - Considerable computational expense can be avoided if perfect forward - secrecy is not a requirement for the session key derivation. The two - parties can exchange nonces and secret key parts to achieve the - authentication and derive keying material. The long-term privacy of - data protected with derived keying material is dependent on the - private keys of each of the parties. - - - - - -Orman Informational [Page 17] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - In this exchange, the GRP has the value 0 and the field for the group - exponential is used to hold a nonce value instead. - - As in the previous section, the first proposed algorithm must be a - public key encryption system; by responding with a cookie and a non- - zero exponential field, the Responder implicitly accepts the first - proposal and the lack of perfect forward secrecy for the identities - and derived keying material. - - Initiator Responder - --------- --------- - -> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, -> - ID(R'), E{ID(I), ID(R), sKi}Kr', Ni - <- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, - E{ID(R), ID(I), sKr}Ki, Nr, - prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <- - -> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, - prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) -> - - Kir = prf(0, sKi | sKr) - - NB The sKi and sKr values go into the nonce fields. The change in - notation is meant to emphasize that their entropy is critical to - setting the keying material. - - NB "NIDP" means that the PFS option for hiding identities is not - used. - - The result of this exchange is a key with KEYID = CKY-I|CKY-R and - value sKEYID = prf(Kir, CKY-I | CKY-R). - -2.4.3 A Conservative Example - - In this example the two parties are minimally aggressive; they use - the cookie exchange to delay creation of state, and they use perfect - forward secrecy to protect the identities. For this example, they - use public key encryption for authentication; digital signatures or - pre-shared keys can also be used, as illustrated previously. The - conservative example here does not change the use of nonces, prf's, - etc., but it does change how much information is transmitted in each - message. - - The responder considers the ability of the initiator to repeat CKY-R - as weak evidence that the message originates from a "live" - correspondent on the network and the correspondent is associated with - the initiator's network address. The initiator makes similar - assumptions when CKY-I is repeated to the initiator. - - - - -Orman Informational [Page 18] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - All messages must have either valid cookies or at least one zero - cookie. If both cookies are zero, this indicates a request for a - cookie; if only the initiator cookie is zero, it is a response to a - cookie request. - - Information in messages violating the cookie rules cannot be used for - any OAKLEY operations. - - Note that the Initiator and Responder must agree on one set of EHA - algorithms; there is not one set for the Responder and one for the - Initiator. The Initiator must include at least MD5 and DES in the - initial offer. - - Fields not indicated have null values. - - Initiator Responder - --------- --------- - -> 0, 0, OK_KEYX -> - <- 0, CKY-R, OK_KEYX <- - -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO -> - <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <- - -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*, - ID(I), ID(R), E{Ni}Kr, -> - <- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <- - E{Nr, Ni}Ki, ID(R), ID(I), - prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS ) - -> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP, - prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) -> - - Kir = prf(0, Ni | Nr) - - * when IDP is in effect, authentication payloads are encrypted with - the selected encryption algorithm using the keying material prf(0, - g^xy). (The transform defining the encryption algorithm will - define how to select key bits from the keying material.) This - encryption is in addition to and after any public key encryption. - See Appendix B. - - Note that in the first messages, several fields are omitted from - the description. These fields are present as null values. - - The first exchange allows the Responder to use stateless cookies; if - the responder generates cookies in a manner that allows him to - validate them without saving them, as in Photuris, then this is - possible. Even if the Initiator includes a cookie in his initial - request, the responder can still use stateless cookies by merely - omitting the CKY-I from his reply and by declining to record the - Initiator cookie until it appears in a later message. - - - -Orman Informational [Page 19] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - After the exchange is complete, both parties compute the shared key - material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf" is - the pseudo-random function in class "hash" selected in the EHA list. - - As with the cookies, each party considers the ability of the remote - side to repeat the Ni or Nr value as a proof that Ka, the public key - of party a, speaks for the remote party and establishes its identity. - - In analyzing this exchange, it is important to note that although the - IDP option ensures that the identities are protected with an - ephemeral key g^xy, the authentication itself does not depend on - g^xy. It is essential that the authentication steps validate the g^x - and g^y values, and it is thus imperative that the authentication not - involve a circular dependency on them. A third party could intervene - with a "man-in-middle" scheme to convince the initiator and responder - to use different g^xy values; although such an attack might result in - revealing the identities to the eavesdropper, the authentication - would fail. - -2.4.4 Extra Strength for Protection of Encryption Keys - - The nonces Ni and Nr are used to provide an extra dimension of - secrecy in deriving session keys. This makes the secrecy of the key - depend on two different problems: the discrete logarithm problem in - the group G, and the problem of breaking the nonce encryption scheme. - If RSA encryption is used, then this second problem is roughly - equivalent to factoring the RSA public keys of both the initiator and - responder. - - For authentication, the key type, the validation method, and the - certification requirement must be indicated. - -2.5 Identity and Authentication - -2.5.1 Identity - - In OAKLEY exchanges the Initiator offers Initiator and Responder ID's - -- the former is the claimed identity for the Initiator, and the - latter is the requested ID for the Responder. - - If neither ID is specified, the ID's are taken from the IP header - source and destination addresses. - - If the Initiator doesn't supply a responder ID, the Responder can - reply by naming any identity that the local policy allows. The - Initiator can refuse acceptance by terminating the exchange. - - - - - -Orman Informational [Page 20] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The Responder can also reply with a different ID than the Initiator - suggested; the Initiator can accept this implicitly by continuing the - exchange or refuse it by terminating (not replying). - -2.5.2 Authentication - - The authentication of principals to one another is at the heart of - any key exchange scheme. The Internet community must decide on a - scalable standard for solving this problem, and OAKLEY must make use - of that standard. At the time of this writing, there is no such - standard, though several are emerging. This document attempts to - describe how a handful of standards could be incorporated into - OAKLEY, without attempting to pick and choose among them. - - The following methods can appear in OAKLEY offers: - - a. Pre-shared Keys - When two parties have arranged for a trusted method of - distributing secret keys for their mutual authentication, they can - be used for authentication. This has obvious scaling problems for - large systems, but it is an acceptable interim solution for some - situations. Support for pre-shared keys is REQUIRED. - - The encryption, hash, and authentication algorithm for use with a - pre-shared key must be part of the state information distributed - with the key itself. - - The pre-shared keys have a KEYID and keying material sKEYID; the - KEYID is used in a pre-shared key authentication option offer. - There can be more than one pre-shared key offer in a list. - - Because the KEYID persists over different invocations of OAKLEY - (after a crash, etc.), it must occupy a reserved part of the KEYID - space for the two parties. A few bits can be set aside in each - party's "cookie space" to accommodate this. - - There is no certification authority for pre-shared keys. When a - pre-shared key is used to generate an authentication payload, the - certification authority is "None", the Authentication Type is - "Preshared", and the payload contains - - the KEYID, encoded as two 64-bit quantities, and the result of - applying the pseudorandom hash function to the message body - with the sKEYID forming the key for the function - - - - - - - -Orman Informational [Page 21] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - b. DNS public keys - Security extensions to the DNS protocol [DNSSEC] provide a - convenient way to access public key information, especially for - public keys associated with hosts. RSA keys are a requirement for - secure DNS implementations; extensions to allow optional DSS keys - are a near-term possibility. - - DNS KEY records have associated SIG records that are signed by a - zone authority, and a hierarchy of signatures back to the root - server establishes a foundation for trust. The SIG records - indicate the algorithm used for forming the signature. - - OAKLEY implementations must support the use of DNS KEY and SIG - records for authenticating with respect to IPv4 and IPv6 addresses - and fully qualified domain names. However, implementations are - not required to support any particular algorithm (RSA, DSS, etc.). - - c. RSA public keys w/o certification authority signature PGP - [Zimmerman] uses public keys with an informal method for - establishing trust. The format of PGP public keys and naming - methods will be described in a separate RFC. The RSA algorithm - can be used with PGP keys for either signing or encryption; the - authentication option should indicate either RSA-SIG or RSA-ENC, - respectively. Support for this is OPTIONAL. - - d.1 RSA public keys w/ certificates There are various formats and - naming conventions for public keys that are signed by one or more - certification authorities. The Public Key Interchange Protocol - discusses X.509 encodings and validation. Support for this is - OPTIONAL. - - d.2 DSS keys w/ certificates Encoding for the Digital Signature - Standard with X.509 is described in draft-ietf-ipsec-dss-cert- - 00.txt. Support for this is OPTIONAL; an ISAKMP Authentication - Type will be assigned. - -2.5.3 Validating Authentication Keys - - The combination of the Authentication algorithm, the Authentication - Authority, the Authentication Type, and a key (usually public) define - how to validate the messages with respect to the claimed identity. - The key information will be available either from a pre-shared key, - or from some kind of certification authority. - - Generally the certification authority produces a certificate binding - the entity name to a public key. OAKLEY implementations must be - prepared to fetch and validate certificates before using the public - key for OAKLEY authentication purposes. - - - -Orman Informational [Page 22] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The ISAKMP Authentication Payload defines the Authentication - Authority field for specifying the authority that must be apparent in - the trust hierarchy for authentication. - - Once an appropriate certificate is obtained (see 2.4.3), the - validation method will depend on the Authentication Type; if it is - PGP then the PGP signature validation routines can be called to - satisfy the local web-of-trust predicates; if it is RSA with X.509 - certificates, the certificate must be examined to see if the - certification authority signature can be validated, and if the - hierarchy is recognized by the local policy. - -2.5.4 Fetching Identity Objects - - In addition to interpreting the certificate or other data structure - that contains an identity, users of OAKLEY must face the task of - retrieving certificates that bind a public key to an identifier and - also retrieving auxiliary certificates for certifying authorities or - co-signers (as in the PGP web of trust). - - The ISAKMP Credentials Payload can be used to attach useful - certificates to OAKLEY messages. The Credentials Payload is defined - in Appendix B. - - Support for accessing and revoking public key certificates via the - Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations. - Other retrieval methods can be used when the AUTH class indicates a - preference. - - The Public Key Interchange Protocol discusses a full protocol that - might be used with X.509 encoded certificates. - -2.6 Interface to Cryptographic Transforms - - The keying material computed by the key exchange should have at least - 90 bits of entropy, which means that it must be at least 90 bits in - length. This may be more or less than is required for keying the - encryption and/or pseudorandom function transforms. - - The transforms used with OAKLEY should have auxiliary algorithms - which take a variable precision integer and turn it into keying - material of the appropriate length. For example, a DES algorithm - could take the low order 56 bits, a triple DES algorithm might use - the following: - - K1 = low 56 bits of md5(0|sKEYID) - K2 = low 56 bits of md5(1|sKEYID) - K3 = low 56 bits of md5(2|sKEYID) - - - -Orman Informational [Page 23] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The transforms will be called with the keying material encoded as a - variable precision integer, the length of the data, and the block of - memory with the data. Conversion of the keying material to a - transform key is the responsibility of the transform. - -2.7 Retransmission, Timeouts, and Error Messages - - If a response from the Responder is not elicited in an appropriate - amount of time, the message should be retransmitted by the Initiator. - These retransmissions must be handled gracefully by both parties; the - Responder must retain information for retransmitting until the - Initiator moves to the next message in the protocol or completes the - exchange. - - Informational error messages present a problem because they cannot be - authenticated using only the information present in an incomplete - exchange; for this reason, the parties may wish to establish a - default key for OAKLEY error messages. A possible method for - establishing such a key is described in Appendix B, under the use of - ISA_INIT message types. - - In the following the message type is OAKLEY Error, the KEYID supplies - the H algorithm and key for authenticating the message contents; this - value is carried in the Sig/Prf payload. - - The Error payload contains the error code and the contents of the - rejected message. - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 24] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Initiator-Cookie ~ - / ! ! -KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! ! - ~ Responder-Cookie ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Message Type ! Exch ! Vers ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! SPI (unused) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! SPI (unused) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Error Payload ! - ~ ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Sig/prf Payload - ~ ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The error message will contain the cookies as presented in the - offending message, the message type OAKLEY_ERROR, and the reason for - the error, followed by the rejected message. - - Error messages are informational only, and the correctness of the - protocol does not depend on them. - - Error reasons: - - TIMEOUT exchange has taken too long, state destroyed - AEH_ERROR an unknown algorithm appears in an offer - GROUP_NOT_SUPPORTED GRP named is not supported - EXPONENTIAL_UNACCEPTABLE exponential too large/small or is +-1 - SELECTION_NOT_OFFERED selection does not occur in offer - NO_ACCEPTABLE_OFFERS no offer meets host requirements - AUTHENTICATION_FAILURE signature or hash function fails - RESOURCE_EXCEEDED too many exchanges or too much state info - NO_EXCHANGE_IN_PROGRESS a reply received with no request in progress - - - - - - - -Orman Informational [Page 25] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.8 Additional Security for Privacy Keys: Private Groups - - If the two parties have need to use a Diffie-Hellman key - determination scheme that does not depend on the standard group - definitions, they have the option of establishing a private group. - The authentication need not be repeated, because this stage of the - protocol will be protected by a pre-existing authentication key. As - an extra security measure, the two parties will establish a private - name for the shared keying material, so even if they use exactly the - same group to communicate with other parties, the re-use will not be - apparent to passive attackers. - - Private groups have the advantage of making a widespread passive - attack much harder by increasing the number of groups that would have - to be exhaustively analyzed in order to recover a large number of - session keys. This contrasts with the case when only one or two - groups are ever used; in that case, one would expect that years and - years of session keys would be compromised. - - There are two technical challenges to face: how can a particular user - create a unique and appropriate group, and how can a second party - assure himself that the proposed group is reasonably secure? - - The security of a modular exponentiation group depends on the largest - prime factor of the group size. In order to maximize this, one can - choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q - are prime. However, if P = kQ + 1, where k is small, then the - strength of the group is still considerable. These groups are known - as Schnorr subgroups, and they can be found with much less - computational effort than Sophie-Germaine primes. - - Schnorr subgroups can also be validated efficiently by using probable - prime tests. - - It is also fairly easy to find P, k, and Q such that the largest - prime factor can be easily proven to be Q. - - We estimate that it would take about 10 minutes to find a new group - of about 2^1024 elements, and this could be done once a day by a - scheduled process; validating a group proposed by a remote party - would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC - machine. - - We note that validation is done only between previously mutually - authenticated parties, and that a new group definition always follows - and is protected by a key established using a well-known group. - There are five points to keep in mind: - - - - -Orman Informational [Page 26] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - a. The description and public identifier for the new group are - protected by the well-known group. - - b. The responder can reject the attempt to establish the new - group, either because he is too busy or because he cannot validate - the largest prime factor as being sufficiently large. - - c. The new modulus and generator can be cached for long periods of - time; they are not security critical and need not be associated - with ongoing activity. - - d. Generating a new g^x value periodically will be more expensive - if there are many groups cached; however, the importance of - frequently generating new g^x values is reduced, so the time - period can be lengthened correspondingly. - - e. All modular exponentiation groups have subgroups that are - weaker than the main group. For Sophie Germain primes, if the - generator is a square, then there are only two elements in the - subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already - recommended avoiding. For Schnorr subgroups with k not equal to - 2, the subgroup can be avoided by checking that the exponential is - not a kth root of 1 (e^k != 1 mod p). - -2.8.1 Defining a New Group - - This section describes how to define a new group. The description of - the group is hidden from eavesdroppers, and the identifier assigned - to the group is unique to the two parties. Use of the new group for - Diffie-Hellman key exchanges is described in the next section. - - The secrecy of the description and the identifier increases the - difficulty of a passive attack, because if the group descriptor is - not known to the attacker, there is no straightforward and efficient - way to gain information about keys calculated using the group. - - Only the description of the new group need be encrypted in this - exchange. The hash algorithm is implied by the OAKLEY session named - by the group. The encryption is the encryption function of the - OAKLEY session. - - The descriptor of the new group is encoded in the new group payload. - The nonces are encoded in the Authentication Payload. - - Data beyond the encryption boundary is encrypted using the transform - named by the KEYID. - - - - - -Orman Informational [Page 27] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The following messages use the ISAKMP Key Exchange Identifier OAKLEY - New Group. - - To define a new modular exponentiation group: - - Initiator Responder - --------- ---------- - -> KEYID, -> - INEWGRP, - Desc(New Group), Na - prf(sKEYID, Desc(New Group) | Na) - - <- KEYID, - INEWGRPRS, - Na, Nb - prf(sKEYID, Na | Nb | Desc(New Group)) <- - - -> KEYID, - INEWGRPACK - prf(sKEYID, Nb | Na | Desc(New Group)) -> - - These messages are encrypted at the encryption boundary using the key - indicated. The hash value is placed in the "digital signature" field - (see Appendix B). - - New GRP identifier = trunc16(Na) | trunc16(Nb) - - (trunc16 indicates truncation to 16 bits; the initiator and - responder must use nonces that have distinct upper bits from any - used for current GRPID's) - - Desc(G) is the encoding of the descriptor for the group descriptor - (see Appendix A for the format of a group descriptor) - - The two parties must store the mapping between the new group - identifier GRP and the group descriptor Desc(New Group). They must - also note the identities used for the KEYID and copy these to the - state for the new group. - - Note that one could have the same group descriptor associated with - several KEYID's. Pre-calculation of g^x values may be done based - only on the group descriptor, not the private group name. - -2.8.2 Deriving a Key Using a Private Group - - Once a private group has been established, its group id can be used - in the key exchange messages in the GRP position. No changes to the - protocol are required. - - - -Orman Informational [Page 28] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.9 Quick Mode: New Keys From Old, - - When an authenticated KEYID and associated keying material sKEYID - already exist, it is easy to derive additional KEYID's and keys - sharing similar attributes (GRP, EHA, etc.) using only hashing - functions. The KEYID might be one that was derived in Main Mode, for - example. - - On the other hand, the authenticated key may be a manually - distributed key, one that is shared by the initiator and responder - via some means external to OAKLEY. If the distribution method has - formed the KEYID using appropriately unique values for the two halves - (CKY-I and CKY-R), then this method is applicable. - - In the following, the Key Exchange Identifier is OAKLEY Quick Mode. - The nonces are carried in the Authentication Payload, and the prf - value is carried in the Authentication Payload; the Authentication - Authority is "None" and the type is "Pre-Shared". - - The protocol is: - - Initiator Responder - --------- --------- - -> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) -> - <- KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni) <- - -> KEYID, INEWKRP, 0, prf(sKEYID, 0 | Ni | Nr) -> - - The New KEYID, NKEYID, is Ni | Nr - - sNKEYID = prf(sKEYID, Ni | Nr ) - - The identities and EHA values associated with NKEYID are the same as - those associated with KEYID. - - Each party must validate the hash values before using the new key for - any purpose. - -2.10 Defining and Using Pre-Distributed Keys - - If a key and an associated key identifier and state information have - been distributed manually, then the key can be used for any OAKLEY - purpose. The key must be associated with the usual state - information: ID's and EHA algorithms. - - Local policy dictates when a manual key can be included in the OAKLEY - database. For example, only privileged users would be permitted to - introduce keys associated with privileged ID's, an unprivileged user - could only introduce keys associated with her own ID. - - - -Orman Informational [Page 29] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.11 Distribution of an External Key - - Once an OAKLEY session key and ancillary algorithms are established, - the keying material and the "H" algorithm can be used to distribute - an externally generated key and to assign a KEYID to it. - - In the following, KEYID represents an existing, authenticated OAKLEY - session key, and sNEWKEYID represents the externally generated keying - material. - - In the following, the Key Exchange Identifier is OAKLEY External - Mode. The Key Exchange Payload contains the new key, which is - protected - - Initiator Responder - --------- --------- - -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni) -> - <- KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni) <- - -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) -> - - Kir = prf(sKEYID, Ni | Nr) - - * this field is carried in the Key Exchange Payload. - - Each party must validate the hash values using the "H" function in - the KEYID state before changing any key state information. - - The new key is recovered by the Responder by calculating the xor of - the field in the Authentication Payload with the Kir value. - - The new key identifier, naming the keying material sNEWKEYID, is - prf(sKEYID, 1 | Ni | Nr). - - Note that this exchange does not require encryption. Hugo Krawcyzk - suggested the method and noted its advantage. - -2.11.1 Cryptographic Strength Considerations - - The strength of the key used to distribute the external key must be - at least equal to the strength of the external key. Generally, this - means that the length of the sKEYID material must be greater than or - equal to the length of the sNEWKEYID material. - - The derivation of the external key, its strength or intended use are - not addressed by this protocol; the parties using the key must have - some other method for determining these properties. - - - - - -Orman Informational [Page 30] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - As of early 1996, it appears that for 90 bits of cryptographic - strength, one should use a modular exponentiation group modulus of - 2000 bits. For 128 bits of strength, a 3000 bit modulus is required. - -3. Specifying and Deriving Security Associations - - When a security association is defined, only the KEYID need be given. - The responder should be able to look up the state associated with the - KEYID value and find the appropriate keying material, sKEYID. - - Deriving keys for use with IPSEC protocols such as ESP or AH is a - subject covered in the ISAKMP/Oakley Resolution document. That - document also describes how to negotiate acceptable parameter sets - and identifiers for ESP and AH, and how to exactly calculate the - keying material for each instance of the protocols. Because the - basic keying material defined here (g^xy) may be used to derive keys - for several instances of ESP and AH, the exact mechanics of using - one-way functions to turn g^xy into several unique keys is essential - to correct usage. - -4. ISAKMP Compatibility - - OAKLEY uses ISAKMP header and payload formats, as described in the - text and in Appendix B. There are particular noteworthy extensions - beyond the version 4 draft. - -4.1 Authentication with Existing Keys - - In the case that two parties do not have suitable public key - mechanisms in place for authenticating each other, they can use keys - that were distributed manually. After establishment of these keys - and their associated state in OAKLEY, they can be used for - authentication modes that depend on signatures, e.g. Aggressive Mode. - - When an existing key is to appear in an offer list, it should be - indicated with an Authentication Algorithm of ISAKMP_EXISTING. This - value will be assigned in the ISAKMP RFC. - - When the authentication method is ISAKMP_EXISTING, the authentication - authority will have the value ISAKMP_AUTH_EXISTING; the value for - this field must not conflict with any authentication authority - registered with IANA and is defined in the ISAKMP RFC. - - - - - - - - - -Orman Informational [Page 31] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The authentication payload will have two parts: - - the KEYID for the pre-existing key - - the identifier for the party to be authenticated by the pre- - existing key. - - The pseudo-random function "H" in the state information for that - KEYID will be the signature algorithm, and it will use the keying - material for that key (sKEYID) when generating or checking the - validity of message data. - - E.g. if the existing key has an KEYID denoted by KID and 128 bits of - keying material denoted by sKID and "H" algorithm a transform named - HMAC, then to generate a "signature" for a data block, the output of - HMAC(sKID, data) will be the corresponding signature payload. - - The KEYID state will have the identities of the local and remote - parties for which the KEYID was assigned; it is up to the local - policy implementation to decide when it is appropriate to use such a - key for authenticating other parties. For example, a key distributed - for use between two Internet hosts A and B may be suitable for - authenticating all identities of the form "alice@A" and "bob@B". - -4.2 Third Party Authentication - - A local security policy might restrict key negotiation to trusted - parties. For example, two OAKLEY daemons running with equal - sensitivity labels on two machines might wish to be the sole arbiters - of key exchanges between users with that same sensitivity label. In - this case, some way of authenticating the provenance of key exchange - requests is needed. I.e., the identities of the two daemons should - be bound to a key, and that key will be used to form a "signature" - for the key exchange messages. - - The Signature Payload, in Appendix B, is for this purpose. This - payload names a KEYID that is in existence before the start of the - current exchange. The "H" transform for that KEYID is used to - calculate an integrity/authentication value for all payloads - preceding the signature. - - Local policy can dictate which KEYID's are appropriate for signing - further exchanges. - - - - - - - - -Orman Informational [Page 32] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -4.3 New Group Mode - - OAKLEY uses a new KEI for the exchange that defines a new group. - -5. Security Implementation Notes - - Timing attacks that are capable of recovering the exponent value used - in Diffie-Hellman calculations have been described by Paul Kocher - [Kocher]. In order to nullify the attack, implementors must take - pains to obscure the sequence of operations involved in carrying out - modular exponentiations. - - A "blinding factor" can accomplish this goal. A group element, r, is - chosen at random. When an exponent x is chosen, the value r^(-x) is - also calculated. Then, when calculating (g^y)^x, the implementation - will calculate this sequence: - - A = (rg^y) - B = A^x = (rg^y)^x = (r^x)(g^(xy)) - C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) - - The blinding factor is only necessary if the exponent x is used more - than 100 times (estimate by Richard Schroeppel). - -6. OAKLEY Parsing and State Machine - - There are many pathways through OAKLEY, but they follow a left-to- - right parsing pattern of the message fields. - - The initiator decides on an initial message in the following order: - - 1. Offer a cookie. This is not necessary but it helps with - aggressive exchanges. - - 2. Pick a group. The choices are the well-known groups or any - private groups that may have been negotiated. The very first - exchange between two Oakley daemons with no common state must - involve a well-known group (0, meaning no group, is a well-known - group). Note that the group identifier, not the group descriptor, - is used in the message. - - If a non-null group will be used, it must be included with the - first message specifying EHAO. It need not be specified until - then. - - 3. If PFS will be used, pick an exponent x and present g^x. - - 4. Offer Encryption, Hash, and Authentication lists. - - - -Orman Informational [Page 33] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 5. Use PFS for hiding the identities - - If identity hiding is not used, then the initiator has this - option: - - 6. Name the identities and include authentication information - - The information in the authentication section depends on the first - authentication offer. In this aggressive exchange, the Initiator - hopes that the Responder will accept all the offered information and - the first authentication method. The authentication method - determines the authentication payload as follows: - - 1. Signing method. The signature will be applied to all the - offered information. - - 2. A public key encryption method. The algorithm will be used to - encrypt a nonce in the public key of the requested Responder - identity. There are two cases possible, depending on whether or - not identity hiding is used: - - a. No identity hiding. The ID's will appear as plaintext. - b. Identity hiding. A well-known ID, call it R', will appear - as plaintext in the authentication payload. It will be - followed by two ID's and a nonce; these will be encrypted using - the public key for R'. - - 3. A pre-existing key method. The pre-existing key will be used - to encrypt a nonce. If identity hiding is used, the ID's will be - encrypted in place in the payload, using the "E" algorithm - associated with the pre-existing key. - - The Responder can accept all, part or none of the initial message. - - The Responder accepts as many of the fields as he wishes, using the - same decision order as the initiator. At any step he can stop, - implicitly rejecting further fields (which will have null values in - his response message). The minimum response is a cookie and the GRP. - - 1. Accept cookie. The Responder may elect to record no state - information until the Initiator successfully replies with a cookie - chosen by the responder. If so, the Responder replies with a - cookie, the GRP, and no other information. - - 2. Accept GRP. If the group is not acceptable, the Responder will - not reply. The Responder may send an error message indicating the - the group is not acceptable (modulus too small, unknown - identifier, etc.) Note that "no group" has two meanings during - - - -Orman Informational [Page 34] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - the protocol: it may mean the group is not yet specified, or it - may mean that no group will be used (and thus PFS is not - possible). - - 3. Accept the g^x value. The Responder indicates his acceptance - of the g^x value by including his own g^y value in his reply. He - can postpone this by ignoring g^x and putting a zero length g^y - value in his reply. He can also reject the g^x value with an - error message. - - 4. Accept one element from each of the EHA lists. The acceptance - is indicated by a non-zero proposal. - - 5. If PFS for identity hiding is requested, then no further data - will follow. - - 6. If the authentication payload is present, and if the first item - in the offered authentication class is acceptable, then the - Responder must validate/decrypt the information in the - authentication payload and signature payload, if present. The - Responder should choose a nonce and reply using the same - authentication/hash algorithm as the Initiator used. - - The Initiator notes which information the Responder has accepted, - validates/decrypts any signed, hashed, or encrypted fields, and if - the data is acceptable, replies in accordance to the EHA methods - selected by the Responder. The Initiator replies are distinguished - from his initial message by the presence of the non-zero value for - the Responder cookie. - - The output of the signature or prf function will be encoded as a - variable precision integer as described in Appendix C. The KEYID - will indicate KEYID that names keying material and the Hash or - Signature function. - -7. The Credential Payload - - Useful certificates with public key information can be attached to - OAKLEY messages using Credential Payloads as defined in the ISAKMP - document. It should be noted that the identity protection option - applies to the credentials as well as the identities. - -Security Considerations - - The focus of this document is security; hence security considerations - permeate this memo. - - - - - -Orman Informational [Page 35] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -Author's Address - - Hilarie K. Orman - Department of Computer Science - University of Arizona - - EMail: ho@darpa.mil - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 36] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX A Group Descriptors - - Three distinct group representations can be used with OAKLEY. Each - group is defined by its group operation and the kind of underlying - field used to represent group elements. The three types are modular - exponentiation groups (named MODP herein), elliptic curve groups over - the field GF[2^N] (named EC2N herein), and elliptic curve groups over - GF[P] (named ECP herein) For each representation, many distinct - realizations are possible, depending on parameter selection. - - With a few exceptions, all the parameters are transmitted as if they - were non-negative multi-precision integers, using the format defined - in this appendix (note, this is distinct from the encoding in - Appendix C). Every multi-precision integer has a prefixed length - field, even where this information is redundant. - - For the group type EC2N, the parameters are more properly thought of - as very long bit fields, but they are represented as multi-precision - integers, (with length fields, and right-justified). This is the - natural encoding. - - MODP means the classical modular exponentiation group, where the - operation is to calculate G^X (mod P). The group is defined by the - numeric parameters P and G. P must be a prime. G is often 2, but - may be a larger number. 2 <= G <= P-2. - - ECP is an elliptic curve group, modulo a prime number P. The - defining equation for this kind of group is - Y^2 = X^3 + AX + B The group operation is taking a multiple of an - elliptic-curve point. The group is defined by 5 numeric parameters: - The prime P, two curve parameters A and B, and a generator (X,Y). - A,B,X,Y are all interpreted mod P, and must be (non-negative) - integers less than P. They must satisfy the defining equation, - modulo P. - - EC2N is an elliptic curve group, over the finite field F[2^N]. The - defining equation for this kind of group is - Y^2 + XY = X^3 + AX^2 + B (This equation differs slightly from the - mod P case: it has an XY term, and an AX^2 term instead of an AX - term.) - - We must specify the field representation, and then the elliptic - curve. The field is specified by giving an irreducible polynomial - (mod 2) of degree N. This polynomial is represented as an integer of - size between 2^N and 2^(N+1), as if the defining polynomial were - evaluated at the value U=2. - - - - - -Orman Informational [Page 37] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - For example, the field defined by the polynomial U^155 + U^62 + 1 is - represented by the integer 2^155 + 2^62 + 1. The group is defined by - 4 more parameters, A,B,X,Y. These parameters are elements of the - field GF[2^N], and can be thought of as polynomials of degree < N, - with (mod 2) coefficients. They fit in N-bit fields, and are - represented as integers < 2^N, as if the polynomial were evaluated at - U=2. For example, the field element U^2 + 1 would be represented by - the integer 2^2+1, which is 5. The two parameters A and B define the - curve. A is frequently 0. B must not be 0. The parameters X and Y - select a point on the curve. The parameters A,B,X,Y must satisfy the - defining equation, modulo the defining polynomial, and mod 2. - - Group descriptor formats: - - Type of group: A two-byte field, - assigned values for the types "MODP", "ECP", "EC2N" - will be defined (see ISAKMP-04). - Size of a field element, in bits. This is either Ceiling(log2 P) - or the degree of the irreducible polynomial: a 32-bit integer. - The prime P or the irreducible field polynomial: a multi-precision - integer. - The generator: 1 or 2 values, multi-precision integers. - EC only: The parameters of the curve: 2 values, multi-precision - integers. - - The following parameters are Optional (each of these may appear - independently): - a value of 0 may be used as a place-holder to represent an unspecified - parameter; any number of the parameters may be sent, from 0 to 3. - - The largest prime factor: the encoded value that is the LPF of the - group size, a multi-precision integer. - - EC only: The order of the group: multi-precision integer. - (The group size for MODP is always P-1.) - - Strength of group: 32-bit integer. - The strength of the group is approximately the number of key-bits - protected. - It is determined by the log2 of the effort to attack the group. - It may change as we learn more about cryptography. - - This is a generic example for a "classic" modular exponentiation group: - Group type: "MODP" - Size of a field element in bits: Log2 (P) rounded *up*. A 32bit - integer. - Defining prime P: a multi-precision integer. - Generator G: a multi-precision integer. 2 <= G <= P-2. - - - -Orman Informational [Page 38] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - <optional> - Largest prime factor of P-1: the multi-precision integer Q - Strength of group: a 32-bit integer. We will specify a formula - for calculating this number (TBD). - - This is a generic example for an elliptic curve group, mod P: - Group type: "ECP" - Size of a field element in bits: Log2 (P) rounded *up*, - a 32 bit integer. - Defining prime P: a multi-precision integer. - Generator (X,Y): 2 multi-precision integers, each < P. - Parameters of the curve A,B: 2 multi-precision integers, each < P. - <optional> - Largest prime factor of the group order: a multi-precision integer. - Order of the group: a multi-precision integer. - Strength of group: a 32-bit integer. Formula TBD. - - This is a specific example for an elliptic curve group: - Group type: "EC2N" - Degree of the irreducible polynomial: 155 - Irreducible polynomial: U^155 + U^62 + 1, represented as the - multi-precision integer 2^155 + 2^62 + 1. - Generator (X,Y) : represented as 2 multi-precision integers, each - < 2^155. - For our present curve, these are (decimal) 123 and 456. Each is - represented as a multi-precision integer. - Parameters of the curve A,B: represented as 2 multi-precision - integers, each < 2^155. - For our present curve these are 0 and (decimal) 471951, represented - as two multi-precision integers. - - <optional> - Largest prime factor of the group order: - - 3805993847215893016155463826195386266397436443, - - represented as a multi-precision integer. - The order of the group: - - 45671926166590716193865565914344635196769237316 - - represented as a multi-precision integer. - - Strength of group: 76, represented as a 32-bit integer. - - The variable precision integer encoding for group descriptor fields - is the following. This is a slight variation on the format defined - in Appendix C in that a fixed 16-bit value is used first, and the - - - -Orman Informational [Page 39] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - length is limited to 16 bits. However, the interpretation is - otherwise identical. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Fixed value (TBD) ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - . . - . Integer . - . . - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - The format of a group descriptor is: - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!1! Group Description ! MODP ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Field Size ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Prime ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Generator1 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Generator2 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Curve-p1 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Curve-p2 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Largest Prime Factor ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Orman Informational [Page 40] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - !1!0! Order of Group ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !0!0! Strength of Group ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 41] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX B Message formats - - The encodings of Oakley messages into ISAKMP payloads is deferred to - the ISAKMP/Oakley Resolution document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 42] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX C Encoding a variable precision integer. - - Variable precision integers will be encoded as a 32-bit length field - followed by one or more 32-bit quantities containing the - representation of the integer, aligned with the most significant bit - in the first 32-bit item. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! first value word (most significant bits) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ additional value words ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - An example of such an encoding is given below, for a number with 51 - bits of significance. The length field indicates that 2 32-bit - quantities follow. The most significant non-zero bit of the number - is in bit 13 of the first 32-bit quantity, the low order bits are in - the second 32-bit quantity. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 1 0! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - - - -Orman Informational [Page 43] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX D Cryptographic strengths - - The Diffie-Hellman algorithm is used to compute keys that will be - used with symmetric algorithms. It should be no easier to break the - Diffie-Hellman computation than it is to do an exhaustive search over - the symmetric key space. A recent recommendation by an group of - cryptographers [Blaze] has recommended a symmetric key size of 75 - bits for a practical level of security. For 20 year security, they - recommend 90 bits. - - Based on that report, a conservative strategy for OAKLEY users would - be to ensure that their Diffie-Hellman computations were as secure as - at least a 90-bit key space. In order to accomplish this for modular - exponentiation groups, the size of the largest prime factor of the - modulus should be at least 180 bits, and the size of the modulus - should be at least 1400 bits. For elliptic curve groups, the LPF - should be at least 180 bits. - - If long-term secrecy of the encryption key is not an issue, then the - following parameters may be used for the modular exponentiation - group: 150 bits for the LPF, 980 bits for the modulus size. - - The modulus size alone does not determine the strength of the - Diffie-Hellman calculation; the size of the exponent used in - computing powers within the group is also important. The size of the - exponent in bits should be at least twice the size of any symmetric - key that will be derived from it. We recommend that ISAKMP - implementors use at least 180 bits of exponent (twice the size of a - 20-year symmetric key). - - The mathematical justification for these estimates can be found in - texts that estimate the effort for solving the discrete log problem, - a task that is strongly related to the efficiency of using the Number - Field Sieve for factoring large integers. Readers are referred to - [Stinson] and [Schneier]. - - - - - - - - - - - - - - - - -Orman Informational [Page 44] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX E The Well-Known Groups - - The group identifiers: - - 0 No group (used as a placeholder and for non-DH exchanges) - 1 A modular exponentiation group with a 768 bit modulus - 2 A modular exponentiation group with a 1024 bit modulus - 3 A modular exponentiation group with a 1536 bit modulus (TBD) - 4 An elliptic curve group over GF[2^155] - 5 An elliptic curve group over GF[2^185] - - values 2^31 and higher are used for private group identifiers - - Richard Schroeppel performed all the mathematical and computational - work for this appendix. - - Classical Diffie-Hellman Modular Exponentiation Groups - - The primes for groups 1 and 2 were selected to have certain - properties. The high order 64 bits are forced to 1. This helps the - classical remainder algorithm, because the trial quotient digit can - always be taken as the high order word of the dividend, possibly +1. - The low order 64 bits are forced to 1. This helps the Montgomery- - style remainder algorithms, because the multiplier digit can always - be taken to be the low order word of the dividend. The middle bits - are taken from the binary expansion of pi. This guarantees that they - are effectively random, while avoiding any suspicion that the primes - have secretly been selected to be weak. - - Because both primes are based on pi, there is a large section of - overlap in the hexadecimal representations of the two primes. The - primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also - prime), to have the maximum strength against the square-root attack - on the discrete logarithm problem. - - The starting trial numbers were repeatedly incremented by 2^64 until - suitable primes were located. - - Because these two primes are congruent to 7 (mod 8), 2 is a quadratic - residue of each prime. All powers of 2 will also be quadratic - residues. This prevents an opponent from learning the low order bit - of the Diffie-Hellman exponent (AKA the subgroup confinement - problem). Using 2 as a generator is efficient for some modular - exponentiation algorithms. [Note that 2 is technically not a - generator in the number theory sense, because it omits half of the - possible residues mod P. From a cryptographic viewpoint, this is a - virtue.] - - - - -Orman Informational [Page 45] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -E.1. Well-Known Group 1: A 768 bit prime - - The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its - decimal value is - 155251809230070893513091813125848175563133404943451431320235 - 119490296623994910210725866945387659164244291000768028886422 - 915080371891804634263272761303128298374438082089019628850917 - 0691316593175367469551763119843371637221007210577919 - - This has been rigorously verified as a prime. - - The representation of the group in OAKLEY is - - Type of group: "MODP" - Size of field element (bits): 768 - Prime modulus: 21 (decimal) - Length (32 bit words): 24 - Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - Generator: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 2 - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 24 - Data (hex): - 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 - 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E - F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 - F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 00000042 - -E.2. Well-Known Group 2: A 1024 bit prime - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its decimal value is - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - - - -Orman Informational [Page 46] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 467627007 - - The primality of the number has been rigorously proven. - - The representation of the group in OAKLEY is - Type of group: "MODP" - Size of field element (bits): 1024 - Prime modulus: 21 (decimal) - Length (32 bit words): 32 - Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - Generator: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 2 - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 32 - Data (hex): - 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 - 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E - F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 - F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 - F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0 - FFFFFFFF FFFFFFFF - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000004D - -E.3. Well-Known Group 3: An Elliptic Curve Group Definition - - The curve is based on the Galois field GF[2^155] with 2^155 field - elements. The irreducible polynomial for the field is u^155 + u^62 + - 1. The equation for the elliptic curve is - - Y^2 + X Y = X^3 + A X + B - - X, Y, A, B are elements of the field. - - For the curve specified, A = 0 and - - B = u^18 + u^17 + u^16 + u^13 + u^12 + u^9 + u^8 + u^7 + u^3 + u^2 + - - - -Orman Informational [Page 47] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - u + 1. - - B is represented in binary as the bit string 1110011001110001111; in - decimal this is 471951, and in hex 7338F. - - The generator is a point (X,Y) on the curve (satisfying the curve - equation, mod 2 and modulo the field polynomial). - - X = u^6 + u^5 + u^4 + u^3 + u + 1 - - and - - Y = u^8 + u^7 + u^6 + u^3. - - The binary bit strings for X and Y are 1111011 and 111001000; in - decimal they are 123 and 456. - - The group order (the number of curve points) is - 45671926166590716193865565914344635196769237316 - which is 12 times the prime - - 3805993847215893016155463826195386266397436443. - (This prime has been rigorously proven.) The generating point (X,Y) - has order 4 times the prime; the generator is the triple of some - curve point. - - OAKLEY representation of this group: - Type of group: "EC2N" - Size of field element (bits): 155 - Irreducible field polynomial: 21 (decimal) - Length (32 bit words): 5 - Data (hex): - 08000000 00000000 00000000 40000000 00000001 - Generator: - X coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 7B - Y coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 1C8 - Elliptic curve parameters: - A parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 0 - B parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 7338F - - - - -Orman Informational [Page 48] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 5 - Data (hex): - 00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B - Group order: 25 (decimal) - Length (32 bit words): 5 - Data (hex): - 08000000 00000000 000057DB 56985371 93AEF944 - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000004C - -E.4. Well-Known Group 4: A Large Elliptic Curve Group Definition - - This curve is based on the Galois field GF[2^185] with 2^185 field - elements. The irreducible polynomial for the field is - - u^185 + u^69 + 1. - - The equation for the elliptic curve is - - Y^2 + X Y = X^3 + A X + B. - - X, Y, A, B are elements of the field. For the curve specified, A = 0 - and - - B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. - - B is represented in binary as the bit string 1111011101001; in - decimal this is 7913, and in hex 1EE9. - - The generator is a point (X,Y) on the curve (satisfying the curve - equation, mod 2 and modulo the field polynomial); - - X = u^4 + u^3 and Y = u^3 + u^2 + 1. - - The binary bit strings for X and Y are 11000 and 1101; in decimal - they are 24 and 13. The group order (the number of curve points) is - - 49039857307708443467467104857652682248052385001045053116, - - which is 4 times the prime - - 12259964326927110866866776214413170562013096250261263279. - - (This prime has been rigorously proven.) - - - -Orman Informational [Page 49] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The generating point (X,Y) has order 2 times the prime; the generator - is the double of some curve point. - - OAKLEY representation of this group: - - Type of group: "EC2N" - Size of field element (bits): 185 - Irreducible field polynomial: 21 (decimal) - Length (32 bit words): 6 - Data (hex): - 02000000 00000000 00000000 00000020 00000000 00000001 - Generator: - X coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 18 - Y coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): D - Elliptic curve parameters: - A parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 0 - B parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 1EE9 - - Optional parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 6 - Data (hex): - 007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF - Group order: 25 (decimal) - Length (32 bit words): 6 - Data (hex): - 01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000005B - -E.5. Well-Known Group 5: A 1536 bit prime - - The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 - }. - Its decimal value is - 241031242692103258855207602219756607485695054850245994265411 - 694195810883168261222889009385826134161467322714147790401219 - 650364895705058263194273070680500922306273474534107340669624 - - - -Orman Informational [Page 50] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 601458936165977404102716924945320037872943417032584377865919 - 814376319377685986952408894019557734611984354530154704374720 - 774996976375008430892633929555996888245787241299381012913029 - 459299994792636526405928464720973038494721168143446471443848 - 8520940127459844288859336526896320919633919 - - The primality of the number has been rigorously proven. - - The representation of the group in OAKLEY is - Type of group: "MODP" - Size of field element (bits): 1536 - Prime modulus: 21 (decimal) - Length (32 bit words): 48 - Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF - Generator: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 2 - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 48 - Data (hex): - 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 - 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E - F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 - F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 - F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E - E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF - C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 - B3861AA7 255E4C02 78BA3604 6511B993 FFFFFFFF FFFFFFFF - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000005B - - - - - - - - - -Orman Informational [Page 51] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -Appendix F Implementing Group Operations - - The group operation must be implemented as a sequence of arithmetic - operations; the exact operations depend on the type of group. For - modular exponentiation groups, the operation is multi-precision - integer multiplication and remainders by the group modulus. See - Knuth Vol. 2 [Knuth] for a discussion of how to implement these for - large integers. Implementation recommendations for elliptic curve - group operations over GF[2^N] are described in [Schroeppel]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 52] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -BIBLIOGRAPHY - - [RFC2401] Atkinson, R., "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC2406] Atkinson, R., "IP Encapsulating Security Payload (ESP)", - RFC 2406, November 1998. - - [RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402, - November 1998. - - [Blaze] Blaze, Matt et al., MINIMAL KEY LENGTHS FOR SYMMETRIC - CIPHERS TO PROVIDE ADEQUATE COMMERCIAL SECURITY. A - REPORT BY AN AD HOC GROUP OF CRYPTOGRAPHERS AND COMPUTER - SCIENTISTS... -- - http://www.bsa.org/policy/encryption/cryptographers.html - - [STS] W. Diffie, P.C. Van Oorschot, and M.J. Wiener, - "Authentication and Authenticated Key Exchanges," in - Designs, Codes and Cryptography, Kluwer Academic - Publishers, 1992, pp. 107 - - [SECDNS] Eastlake, D. and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - [Random] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [Kocher] Kocher, Paul, Timing Attack, - http://www.cryptography.com/timingattack.old/timingattack.html - - [Knuth] Knuth, Donald E., The Art of Computer Programming, Vol. - 2, Seminumerical Algorithms, Addison Wesley, 1969. - - [Krawcyzk] Krawcyzk, Hugo, SKEME: A Versatile Secure Key Exchange - Mechanism for Internet, ISOC Secure Networks and - Distributed Systems Symposium, San Diego, 1996 - - [Schneier] Schneier, Bruce, Applied cryptography: protocols, - algorithms, and source code in C, Second edition, John - Wiley & Sons, Inc. 1995, ISBN 0-471-12845-7, hardcover. - ISBN 0-471-11709-9, softcover. - - [Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with - Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995. - Available on-line as - ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and - .Z). - - - -Orman Informational [Page 53] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - [Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC - Press, Inc., 2000, Corporate Blvd., Boca Raton, FL, - 33431-9868, ISBN 0-8493-8521-0, 1995 - - [Zimmerman] Philip Zimmermann, The Official Pgp User's Guide, - Published by MIT Press Trade, Publication date: June - 1995, ISBN: 0262740176 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 54] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 55] - |